This invention relates generally to automatic test equipment, and more specifically to a software environment for facilitating the development, execution, and documentation of tests performed by automatic test equipment.
Automatic test equipment, also known as a tester, is commonly used to test both semiconductor devices and assembled printed circuit boards to determine whether the devices and boards are defective.
In general, a tester operator develops test signals and test sequences on the tester for subsequent testing of a unit under test (UUT), which may be either a semiconductor device or a printed circuit board. The tester operator then enters commands to start a test, thereby causing the tester to apply the test signals to the UUT and receive output signals produced by the UUT in response to the applied test signals. The tester then typically compares the received output signals with stored expected values. The tester also typically measures various parameters associated with the UUT, such as the amount of current drawn during various operating conditions or the frequency of various output signals, and then compares these values with other expected values. If any of the received signals or measured values do not match corresponding expected values, then the tester typically indicates that the UUT has defects.
The UUT may include just digital or analog circuitry, or both types of circuitry. A UUT that includes both types of circuitry is generally known as a mixed-signal device, and testers that test these devices are generally known as mixed-signal testers.
Such mixed-signal testers are commonly configured with a workstation and several instruments, which are connected to either nodes or primary inputs/outputs of the UUT. The workstation typically controls the instruments via a standard buss, and the instruments typically apply test signals to the UUT, acquire output signals from the UUT, and make any required measurements on the UUT. Some of the instruments may be only used for digital tests, while other instruments may be used just for analog tests. Still other instruments may be used for providing DC signals or power to the UUT. Further, the different instruments are frequently acquired from different instrument manufacturers.
FIG. 1 shows a block diagram of a tester 100, which includes a workstation 102 that controls a plurality of instruments such as instruments 130, 132, and 134 through a buss 110. Further, the instruments 130, 132, and 134 are coupled to nodes or primary inputs/outputs of a UUT 112.
The workstation 102 has a typical software configuration 101, which includes a controller module 106, a plurality of test generation tools such as a tool 104, and a plurality of instrument drivers 120, 122, and 124. Each of the software modules in the software configuration 101 might be created using a textual programming language such as C++ or BASIC. The software configuration 101 might alternatively be implemented using a graphical programming system such as the LabVIEW(trademark) system sold by National Instruments Corporation, Austin, Tex., USA, or the HP VEE(trademark) system sold by Hewlett-Packard Company, Palo Alto, Calif., USA. In this case, the controller module 106 typically implements a user interface on a display monitor (not shown), and the tester operator typically specifies tests to be performed on the UUT 112 by manipulating graphical representations on the display monitor using an input device (not shown) such as a keyboard or mouse. It is generally recognized that computer-based systems that deal with information in a graphical or visual manner are more desirable than those that rely on textual formats.
The drivers 120, 122, and 124 communicate with respective instruments 130, 132, and 134 via the buss 110, which is generally compatible with an interface standard such as HP-IB (IEEE-488), VMEbus, or VXIbus (VMEbus Extensions for Instrumentation). Further, because the UUT 112 may include digital or analog circuitry or both, some of the instruments 130, 132, and 134 may be suited for transmitting/receiving digital signals while other instruments may only deal with analog signals. Still other instruments may provide any necessary DC signals or power to the UUT 112.
During a typical test session, the tester operator uses the test generation tools for specifying digital and/or analog test signals and corresponding expected values. The digital test signals may be applied to a simulator 108, which typically simulates the logic functionality of the UUT 112 and provides patterns of expected output data to the workstation 102. These patterns reflect the output signals that would be produced by a properly functioning UUT in response to the digital test signals. The tester operator then typically saves the specified test signals and corresponding expected values in a database (not shown) included in the workstation 102.
The tester operator also uses the test generation tools for specifying sequences of steps to be performed when testing the UUT 112. For example, steps in a simplified test sequence may include first applying power to the UUT 112. Next, various digital tests may be performed on the UUT 112 followed by analog tests, or vice versa. The final step in the test sequence may include removing power from the UUT 112.
Although the tester 100 has been successfully used for testing semiconductor devices and printed circuit boards, it has some drawbacks. For example, it was described that it is frequently necessary to develop both analog and digital tests for mixed-signal devices or boards. This means that different sequences of steps must be followed in both the development and the execution of the analog and digital tests. Further, the increasing densities of semiconductor devices and printed circuit boards have added a high-level of complexity to the development of such test sequences.
However, the tester 100 lacks features for facilitating the development and execution of these complex test sequences. For example, it was mentioned that graphical programming systems such as LabVIEW(trademark) and HP VEE(trademark) might be used to implement the typical software configuration 101. Such graphical programming systems can be used to implement both user interfaces and test sequences. In particular, the user interfaces might include graphs, drop-down lists, pop-up menus, and graphical representations of knobs, switches, and slides. Further, the test sequences might be graphically represented by block diagrams.
But, these graphical programming systems are primarily useful for specifying test sequences as lists of steps. They are not particularly useful for grouping related steps or for specifying which groups of steps are to be performed in a test. Also, they generally lack features for specifying steps or parameters that might be common to different groups of steps. Also, they generally do not clearly convey the organization of test sequences involving such groups of steps through the user interface. We have recognized that these drawbacks restrict the tester operator""s ability to develop and execute tests for complex devices and boards such as those having both digital and analog circuitry.
Further, the tester 100 lacks features for facilitating the access of documentation relating to a test. Although testers designed using the LabVIEW(trademark) and HP VEE(trademark) graphical programming systems include features for documenting the design and structure of test sequences, they generally do not have features for easily accessing user manuals and other documentation. They also generally do not clearly convey the organization of such documentation through the user interface.
Another drawback of the tester 100 is that the software modules included in the typical software configuration 101 cannot be easily interfaced with other software modules. This is because the software modules are generally implemented with non-standard software constructs such as dynamic link libraries (DLLs). The main shortcoming of such non-standard constructs is that they do not conform to any accepted standard interface. As a result, the software modules are usually dedicated to a particular type of tester and cannot be easily integrated with other testers. This also makes it difficult to add functionality to a tester.
We have also recognized the desirability of having a distributed tester architecture. For example, a local tester might perform test development and control functions while remote testers perform testing and analysis functions. In this way, one tester may be configured to control several other testers. Further, one or more testers might be dedicated to performing data analysis functions, thereby allowing other testers to focus upon collecting test data. Also, data from several testers might be consolidated in a single location.
However, because the software modules included in the typical software configuration 101 are generally implemented in a non-standard manner, they cannot be easily interfaced with applications that would allow such a distributed tester architecture.
It would therefore be desirable to have a tester that facilitates the development, execution, and documentation of complex test sequences. Such a tester would clearly communicate the organization and structure of these test sequences and related documentation to the tester operator through the user interface. It would also be desirable to have a tester that can be easily adapted to a distributed tester architecture.
With the foregoing background in mind, it is an object of the invention to provide a tester that facilitates the development, execution, and documentation of complex test sequences.
Another object of the invention is to provide a tester with a user interface that clearly communicates the organization and structure of complex test sequences and their related documentation.
Still another object of the invention is to provide a tester with a user interface that can be easily integrated with remote testers.
Yet another object of the invention is to provide a tester that can be easily adapted to a distributed tester architecture.
The foregoing and other objects are achieved by specifying a first hierarchical tree of nodes. The nodes in the first tree include at least one end leaf corresponding to a step in a sequence of steps for generating a test program. Next, a second hierarchical tree is specified. The nodes in the second tree include at least one end leaf corresponding to a step in a sequence of steps for executing a test program. The sequence of steps corresponding to the leaves in the first tree is then executed, thereby generating a test program. Further, the sequence of steps corresponding to the leaves in the second tree is executed, thereby executing the test program.
According to one feature, each end leaf in the first and second trees has a plurality of associated properties. At least one of the properties is used for indicating a method to be called during the execution of a corresponding step.
In another embodiment, a system for generating and executing test programs includes a local tester, at least one remote tester, and data transmission lines connecting the local tester with the remote tester. The local tester includes means for generating the test programs, and means for transmitting data representing the test programs to the remote tester. Further, the remote tester includes means for executing the test program.
According to one feature, the local tester and the remote tester exchange data representing the test program and test results through a network, such as a corporate Intranet or the public Internet.
Still further objects and advantages will become apparent from a consideration of the ensuing description and drawings.